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ABSnUCT 
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information  throughout  the  life  cycle.  However,  various  modds  proposed  by  current  researdi  for 
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functionalities  of  a  design  rationale  management  tool  to  use  the  ratioiude  in  various  systmns 
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I.  INTRODUCTION 


K.  BACKGROUND 

Every  year  the  Department  of  Defense's  (DoD)  disbursements 
on  software  alone  amount  to  almost  ten  billion  dollars.  Many 
sources  have  estimated  that  maintenance  costs  comprise  seventy 
to  eighty  percent  of  that  figure.  With  the  shrinking  defense 
budget,  it  becomes  paramount  to  develop  systems  which  are 
easier  and  more  economical  to  maintain  and  inclement  (Endoso, 
1992,  p.  6) . 

Recent  studies  have  recognized  that  effectively  capturing 
and  using  rationale  throughout  the  development  life  cycle  will 
help  decrease  the  rising  costs  of  software  maintenance  (Dhar 
and  Ramesh,  1992,  pp.  498-499).  In  the  later  stages  of  the 
life  cycle,  requirements  and  design  rationale  can  be  useful  in 
chcuige  management  and  can  facilitate  reuse  of  components.  The 
DoD  can  also  utilize  such  data  as  part  of  a  comprehensive 
requirements  tracecdjility  effort. 

Design  rationale  are  often  the  outcome  of  deliberations 
between  members  of  the  design  tecun.  The  goal  of  capturing 
design  deliberations  is  to  ened>le  the  understanding  of 
specifications,  design  components,  or  artifacts,  and  the 
decision  making  process  that  creates  them.  A  historical 


record  of  rationale  identifying  how  the  requirements  and 
design  evolved  will  provide  the  knowledge  necessary  to 
recognize  repercussions  of  changing  the  requirements  in  the 
design  and  the  final  product. 

Capture  emd  maintenance  of  rationale  becomes  even  more 
ixiqportcuit  in  the  context  of  shrinking  DoD  budgets,  as  systems 
are  expected  to  have  longer  and  longer  life  cycles.  Rather 
than  designing  new  systems  increased  attention  is  being  given 
to  modification  of  those  already  in  existence.  Such 
modification  efforts  usually  encompass  three  basic  areas: 
reengineering,  reuse,  and  maintenance;  all  of  which  can  be 
supported  by  the  capture. and  use  of  design  rationale. 

The  first  step  in  any  reengineering  effort  is  the 
understanding  of  the  initial  design  of  the  system.  Having  a 
method  to  identify  the  design  rationale  implemented  in  the 
original  system  will  foster  such  an  understanding.  Reuse 
efforts  will  be  greatly  benefited  by  having  information  on  not 
just  the  artifacts  created,  but  also  how  they  were  created. 

During  maintenance  efforts,  involving  hardware  upgrades  on 
or  inqprovements  to  software,  having  the  design  rationale 
available  may  enable  maintainers  to  make  modifications  without 
unduly  affecting  other  aspects  of  the  system. 

Current  models  for  the  capture  of  design  rationale  are  not 
conprehensive  as  they  address  only  aspects  of  design  rather 
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than  the  entire  design  process.  In  arriving  at  the  basic 
con^onents  of  any  conqprehensive  design  rationale  information 
model,  one  must  first  have  an  understanding  of  design 
processes.  Most  large  scale  design  efforts  involve  design 
teams  rather  than  single  designers  working  independently.  To 
understand  the  design  rationale  which  arise  from  group 
deliberations,  an  appreciation  of  group  dynamics  is  essential. 
At  the  center  of  group  dynamics  is  group  communication. 
Therefore,  a  model  to  capture  design  rationale  must  also 
incorporate  features  which  reflect  aspects  of  group 
communications.  Further,  err^loyment  of  the  model  also 
necessitates  the  exploration  of  mechanisms  which  could  capture 
the  information  necessary  to  populate  the  model  and  facilitate 
the  use. 

B.  OBJECTIVES 

Our  main  goals  in  the  research  are  the  identification  of 
the  components  of  a  rationale  information  model,  mechanisms  to 
facilitate  their  capture,  and  the  generic  functionalities  of 
a  design  rationale  management  tool  to  use  the  rationale  in 
various  systems  development  activities. 

C.  SCOPE 

Our  original  intent  was  to  develop  a  prototype  model  for 
design  rationale  capture  which  could  utilize  current 
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technologies  to  support  their  capture  and  use.  However,  due 
to  unavailaddility  of  hardware  support,  we  refocused  our  goals. 
Our  research  began  with  a  literature  survey  on  current  models 
of  group  work  and  group  communication.  We  then  investigated 
various  models  for  representing  design  rationale.  We 
proceeded  to  examine  methods  for  effective  capture  of  the 
design  rationale.  Literature  on  current  technologies  led  us 
to  focus  on  the  area  of  Computer  Supported  Cooperative  Work 
(CSCW) .  Specifically,  we  reviewed  the  applicability  of 
mechanisms  employing  multimedia  techniques  for  capturing 
design  rationale. 

Besides  current  literature,  other  sources  that  provided 
valuable  information  towards  our  findings  include; 


•  Multimedia  Expo,  Santa  Clara,  California  (October,  1992) 

•  meeting  with  K.  Baudin  and  J.  Givens  at  NASA  Ames,  Palo 
Alto,  California,  to  discuss  current  design  rationale 
tools  such  as  Dedal  (December,  1992) 

•  meeting  V.  Baya  at  Stanford's  Center  for  Design  Research, 
Palo  Alto,  California  (December,  1992) 

•  presentation  given  by  S.  Hashim  on  the  Issue  Based 
Information  System  (IBIS)  at  the  Naval  Postgraduate 
School,  Monterey,  California  (January,  1993) 

•  visit  to  Stanford's  multimedia  lab  to  include  a 
demonstration  of  a  tool  called  Maestro  (February,  1993) 

•  Groupware' 93  conference  and  exhibition,  San  Jose, 
California  (August,  1993) 
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D.  OSGUOfZZATZON  OP  TBB  THSSIS 

Chapters  II  amd  III  explore  what  we  view  as  two  basic 
areas  that  will  facilitate  the  understanding  of  the  design 
process:  specifically,  design  and  communications.  Chapter  IV 
will  describe  current  models,  methodologies,  and  tools  which 
address  the  capture  of  design  rationale.  Finally,  Chapter  V 
will  answer  our  research  questions  by  presenting  components  of 
a  design  rationale  information  model  and  suggesting  basic 
functionalities  to  support  its  capture  and  use.  Chapter  VI 
will  provide  our  recommendations  and  conclusions. 
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II.  DESIGN 


A.  DESIGN  HISTORY 

The  design  process  is  defined  as  "any  activity  that  leads 
to  the  creation  of  artifacts”  (Dhar  and  Ramesh,  1992,  p.  498)  . 
Artifacts  include  any  tangible  output,  such  as  documentation, 
graphical  drawings  and  prototype  products.  Besides  focusing 
on  the  creation  of  artifacts,  the  design  process  also  produces 
information  edjout  the  artifacts  which  are  understandable  and 
useful  not  only  to  the  designers  but  also  to  those  outside  the 
original  design  team.  The  early  stages  of  design  incorporate 
conceptual  ideas  and  formulate  them  into  structured  artifacts 
such  as  design  specifications,  prototypes,  and  graphic 
representation  of  data. 

Different  factors  that  influence  the  design  process 
include  project  task,  project  complexity,  designers' 
experience  and  design  group  size  (Kellogg,  Maass,  and  Rosson, 
1988,  pp.  1288-1298) . 

Project  task  is  the  component  which  describes  the  basic 
nature  of  the  project,  such  as  building  an  interface  from 
scratch  or  redesigning  a  retrieval  mechanism.  The  efforts 
involved  in  creating  an  artifact  from  the  most  basic 
beginnings  may  encompass  a  different  type  of  activity  in 
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contrast  to  modifying  an  artifact  that  already  exists.  Other 
influences  that  may  inpact  the  project  conposition  involve  the 
dynamics  which  surround  the  particular  design  task  such  as 
constrained  or  open-ended  requirements. 

Project  conplexity  describes  the  magnitude  of  technical 
requirements  of  the  project.  For  example,  designing  an 
operating  system  may  be  more  conplex  than  redesigning  a 
database.  Size  of  the  project  is  an  inportant  consideration 
in  this  area  also. 

Each  designer  contributes  his/her  own  individual  and 
diverse  knowledge  into  the  process  which  must  be  collaborated 
within  the  group  to  produce  any  artifact.  7Ui  individual  with 
many  years  of  experience  working  within  a  group  may  not 
articulate  basic  assumptions  cd>out  design  premises  to  other 
group  members;  whereas  novice  designers  working  together  miy 
find  it  necessary  to  articulate  the  most  basic  premises  of  the 
project.  A  group  whose  members  vary  in  experience  level  may 
exhibit  characteristics  of  both. 

It  is  the  collod)oration  of  individuals'  efforts  in  the 
group  atmosphere  that  produces  many  of  today's  large  scale 
systems.  Each  individual  in  the  group  is  influenced  by  other 
group  members.  As  the  size  of  the  group  increases  so  does  the 
conplexity  of  group  interactions. 
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Design  is  an  evolutionary  process  where  the  output  of  each 
cycle  is  used  in  refining  the  input  to  the  next  cycle.  One 
phase  precedes  another  and  all  phases  are  interdependent.  The 
slnplest  of  changes  to  the  early  phases  may  create  influences 
which  have  dramatic  effects  on  the  performance  or  size  of  the 
overall  system.  A  medium  for  tracking  these  early  changes  and 
their  resulting  effect  on  the  overall  system  would  greatly 
facilitate  the  design  process.  However  as  "design  emerges 
from  a  context  of  human  desires  and  needs,  subject  to  all  the 
foibles  of  human  activity,"  (Carroll,  1992,  p.  4)  clearly 
identifying  all  influences  which  lead  to  changes  may  be 
difficult. 

Another  dynamic  in  the  design  process  is  the  incorporation 
of  new  knowledge  into  the  designers'  existing  premises  which 
influence  design  practices.  Learning  arises  from  conparing 
new  information  against  a  mental  template  that  is  formed  by 
past  experience;  the  design  process  likewise  is  refined  by 
constructing  new  ideas  from  the  application  of  existing 
concepts  and  models  into  designers'  existing  premises.  The 
formulation  of  this  new  information  is  predominantly 
necessitated  by  changing  requirements  which  have  their  origins 
outside  the  design  team.  This  refinement  is  what  is  described 
as  the  iterative  process  of  design. 
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As  an  intuitive  process,  we  view  design  as  not  only 
intuitive,  but  conversely,  judgmental  as  well  as  learned. 
Each  member  within  design  tesuns  brings  his/her  personal 
experiences,  learned  skills,  and  expertise  into  the  group.  It 
is  the  combination  of  all  the  mendsers'  individual  backgrounds 
which  gives  each  group  a  unique  set  of  preconceived  notions  or 
insights.  These  notions  and  insights  are  refined  as 
interactions  occur  between  group  members,  thus  the  group  will 
formulate  additional  insights  upon  which  to  base  judgements  in 
the  design  realm. 


While  conscious,  rational  thought  and  preparation  may 
precede  (and  even  be  necessary  for)  such  insight,  the 
insight  itself  is  not  part  of  any  conscious,  formalizable 
process.  It  is  the  designer's  intuition  that  pulls 
together  the  appropriate  parts  of  his  knowledge  that  'have 

no  affinity  apart  from _ intuitive  understanding'  and 

drives  the  software  input  to  output  transformation 
(Carroll,  1992,  p.  9). 


Capturing  the  rationale  underlying  the  design  process  may 
provide  tangible  insights  into  the  formulation  of  group 
intuition. 

When  a  decision  is  required  in  the  design  process,  the 
designer  could  examine  different  alternatives.  Each  time  an 
alternative  is  chosen  or  discarded  a  possibility  exists  to 
gain  knowledge  from  recording  such  an  interaction;  information 
drawn  from  the  recording  could  provide  insight  into 
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understanding  amd  modifying  the  design  process.  Often,  the 
reflection  of  the  alternative  chosen  is  clear  in  project 
artifacts;  however  there  may  not  be  sufficient  documentation 
or  tracking  of  alternatives  which  were  not  chosen. 
Information  regarding  those  alternatives  not  chosen  should 
also  be  maintained  in  cm  understandaible  format  because  they 
may  become  relevant  with  the  addition  of  new  or  changing 
requirements . 

B.  DESIGN  RATIONALE 

Design  rationale  is  the  reasoning  behind  or  decision 
making  process  involved  in  the  creation  of  an  artifact  (Dhar 
euid  Ramesh,  1992,  p.  498;  Grueber  and  Russell,  1992,  p.  Ill) . 
Design  rationale  serves  multiple  purposes:  definition  of 
unstated  assuirqptions,  clarification  of  dependencies  and 
constraints,  and  justification  or  validation  of  design 
decisions  (Grueber  and  Russell,  1992,  pp.  111-118). 
Greenbaiom  and  Kyng  fittingly  described  the  purpose  of  design 
rationale  when  they  stated  the  following: 

A  user  wanting  to  change  a  system  will  want  to  know  what 
changes  are  already  there  and  their  history.  This  history 
includes  the  changes  that  have  been  made,  who  made  them, 
and  for  what  purpose,  including  the  work  practices  that 
the  user  had  in  mind  when  modifying  the  system.  All  of 
this  is  needed  for  people  to  be  cdsle  to  continue  to  evolve 
the  system  coherently  (Greenbaum  and  Kyng,  1991,  p.  234) . 
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Although  the  formulation  of  design  rationale  is  an 
integral  part  of  design,  capturing  design  rationale  is 
sometimes  a  time-consuming,  secondary  concern.  A  basic 
question  to  answer  would  be,  "why  even  bother?"  To  think  that 
design  starts  from  scratch  is  an  unrealistic  assunqption;  with 
the  incorporation  of  design  rationale  designers  are  6d>le  to 
prevent  the  phenomena  know  as  "reinventing  the  wheel."  Some 
of  the  attainable  advantages  made  possible  by  design  rationale 
capture  include: 

•  cost  savings  realized  from  less  time  spent  on  repetitive 
decisions 

•  in^rovement  of  the  quality  of  artifacts  due  to  the 
incorporation  of  past  decisions 

•  enabling  designers  to  incorporate  lessons  learned  from 
others 

•  supporting  linkages  between  associated  artifacts 

•  preventing  loss  of  information 

•  providing  a  tracking  system  for  decisions 

•  fostering  accountedaility  (Jarczyk,  Loeffler,  and  Shipman, 
1992,  pp.  577-586). 

Just  as  each  project's  design  rationale  will  differ,  the 
benefits  afforded  by  the  capture  will  vary  from  scenario  to 
scenario. 
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C.  DBSZGN  BSaSB 


Once  captured,  design  rationale  must  be  used  in  order  to 
derive  any  benefits;  the  use  of  existing  artifacts,  of  which 
design  rationale  is  the  principal  artifact,  is  referred  to  as 
design  reuse.  Typically,  only  the  reuse  of  artifacts  such  as 
code  is  attempted  in  reuse  efforts.  The  availaJsility  of 
design  rationale  will  greatly  enhance  the  potential  of 
artifacts  not  traditionally  utilized  in  reuse  efforts.  By 
capturing  the  design  rationale  which  lead  to  particular 
artifacts,  information  on  the  context  in  which  the  artifact 
was  developed  may  be  evaluated.  Additionally,  incorporation 
of  design  rationale  may  facilitate  the  "tailoring"  of  existing 
artifacts  for  reuse  in  current  contexts. 

Even  more  in^orteuit  than  examining  the  artifacts  is  the 
ability  to  incorporate  the  process  by  which  they  were  created. 
Now,  instead  of  just  asking  the  question,  "What  should  be 
examined, "  designers  are  asking  "Why  was  this  done  the  way  it 
was  done."  Typically  there  is  a  multitude  of  artifacts 
availeUsle  which  reflect  the  results  of  design  decisions,  such 
as  user's  manuals,  design  sketches,  source  code,  etc.,  but 
there  may  be  no  tangible  record  of  the  'eliberations  which 
lead  to  design  decisions.  Effective  reuse  would  enconpass  the 
eUsility  to  discern  the  design  decisions  from  the  design 
deliberations . 
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Once  equipped  with  the  cUbility  to  identify  relevant 
material,  the  next  step  is  the  actual  incorporation  of  this 
information  into  the  process.  The  term,  process,  encompasses 
a  broad  range  of  activities  in  the  design  reuse  realm. 
Designers  may  be  modifying  an  existing  system,  designing  a 
system  to  function  in  a  similar  environment,  designing  a 
system  which  performs  the  same  function,  or  redesigning  the 
total  system  from  the  ground  up;  all  of  these  areas  could 
profit  from  design  rationale  reuse. 
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ZZZ.  COMKOHZCATZOH 


Comnunicatlon  is  a  natural  element  of  every  day  life. 
From  the  time  that  we  are  first  aware  of  our  environment  and 
continuing  throughout  our  life,  we  are  constamtly  utilizing 
amd  refining  our  ability  to  communicate.  Each  of  us  en^loys 
our  own  unique  way  of  communicating.  Understainding  individual 
coonmunication  processes  «uid  how  they  combine  to  form  group 
processes  will  enhance  the  tinderstamding  of  design. 

Designers  or  managers  working  in  the  field  of  software 
design  are  constantly  wondering  what  ceui  be  done  to  improve 
the  process.  They  examine  all  facets  of  the  process  from  the 
beginning  stages  of  design  to  the  creation  of  artifacts  which 
result.  Throughout,  one  factor  is  always  present  and  is  key 
to  all  other  functions,  namely  communication.  This  word, 
communication,  encom^sses  many  realms.  iRiile  it  is  natural 
to  think  of  communication  as  speech  or  the  words  we  use  to 
convey  a  thought,  the  act  of  communicating  enconqpasses  much 
more.  The  basic  building  block  of  communication  is  language. 
"Speech  is  verbal  communication,  while  language  is  the  body  of 


formal  rules  governing  the  use  of  symbols  and  signs,  be  they 
lingual,  vocal,  verbal,  gestural,  or  otherwise  nonverbal” 
(Matson  and  Montagu,  1979,  p.  174). 


A.  ZHDIVIDUAL  SKILLS 

As  a  child  we  begin  to  leam  language  skills  from  our 
parents  and  from  the  influences  that  surround  us.  We  leam 
that  ”a  hurnam  being...  is  never  dependent  on  his  o%m 
experience  alone  for  his  information”  (Hayakawa,  1939,  p.  10)  . 
As  we  grow  older  the  influences  to  which  we  are  subjected 
multiply.  The  most  central  of  these  becomes  our  formal 
education.  Here  we  have  the  adaility  to  leam  from  those 
outside  our  immediate  proximity. 

Instead  of  remaining  helpless  because  of  the 
limitations  of  (ones)  o%m  experience  and  Icnowledge, 
instead  of  having  to  discover  what  others  have  already 
discovered,  instead  of  exploring  the  false  trails  they 
explored  and  repeating  their  errors,  (one)  can  go  on 
from  where  they  left  off  (Hayakawa,  1939,  p.  10) . 

Formal  education,  although  the  cornerstone,  is  not  one's 
sole  source  of  experiential  learning.  A  person's  cultural  and 
social  backgrounds  also  influence  communication  assimilation 
skills.  "People  are  more  than  a  sxnn  of  parts... they  have  a 
set  of  values,  goals,  and  beliefs  edaout  life  and  work" 
(Greenbavim  and  Kyng,  1991,  p.  28)  all  of  which  are  formed  by 
the  influences  which  surround  them.  These  influences  can  have 
a  direct  bearing  on  the  formulation  of  design  rationale  and 
subsequent  reflection  in  the  artifacts.  For  exait^le, 
individuals,  who  from  an  early  age  have  been  fostered  with  a 
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strong  morale  responsibility  from  their  parents,  will  manifest 
that  belief  as  an  adult  in  their  work  place  by  exhibiting 
strong  ethical  work  behaviors.  By  understanding  the 
influences  by  which  design  rationale  are  formulated  we  may  be 
ed}le  to  more  fully  utilize  the  artifacts  of  the  design 
process . 

B.  GROUPS 

Focusing  on  the  area  of  design,  we  realize  that  by 
necessity,  much  work  is  done  in  groups.  Newstorm  and  Pierce 
(1990,  p.  105)  stated: 

Some  tasks  are  too  demanding,  too  difficult,  or  too 
important  to  be  performed  by  individuals.  Because  of 
their  great  potential  for  diverse  perspectives,  their 
combined  breadth  of  member  experiences,  and  the  powerful 
support  they  can  provide  for  decisions  made,  groups 
represent  key  building  blocks  for  organizations. 

There  are  certain  dynamics  involved  when  individuals  come 
together  to  form  a  group.  We  will  focus  on  three  of  these: 
cooperation,  coordination,  and  integration.  Cooperation 
represents  the  state  of  mutual  support  among  individuals 
Coordination  can  be  viewed  as  the  existence  of  actions  that 
are  synchronized  in  some  way  to  produce  a  common  benefit. 
However,  the  mere  presence  of  coordination  does  not 
necessarily  result  in  a  cooperative  relationship  among  the 


individuals  involved.  We  will  refer  to  integration  by  Aronoff 
and  Baskin's  definition  as  a  higher  level  of  organization  that 
includes  both  cooperation  cmd  coordination  to  produce  a 
molding  of  Individuals  amd  activities  into  a  unified  whole 
(Aronoff  and  Baskin,  1980,  pp.  58-64) . 

Integration  is  not  an  automatic  phenomenon,  it  is  the 
result  of  Interaction  between  group  members  over  a  period  of 
time  which  culminates  into  distinct  behavioristic  patterns. 
Group  members  will  develop  expectations  concerning  one 
cuiother's  behavior  in  these  patterns.  In  doing  so,  they  will 
come  to  identify  one  another  as  members  of  the  same  social 
entity  (Aronoff  and  Baskin,  1980,  pp.  58-64) .  This  coming 
together  as  a  unique  entity,  with  certain  expectations,  norms 
and  behaviors  is  what  we  see  as  the  formulation  of  group 
culture. 

Much  has  been  written  cd}out  group  culture.  Webber's 
(1969,  p.  10)  surrealistic  view  of  culture  is  described  as: 

We  are  immersed  in  a  sea.  It  is  warm,  comfortable, 
supportive,  and  protecting.  Most  of  us  float  below  the 
surface;  some  bob  about,  catching  glimpses  of  land  from 
time  to  time;  a  few  emerge  from  the  water  entirely.  The 
sea  is  our  culture. 
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In  contrast,  Kroeber  and  Kluckhohn  (1963,  p.  357)  offer  a  more 
concrete  description: 

Culture  consists  of  patterns,  explicit  and  iirplicit,  of 
and  for  behavior  acquired  and  transmitted  by  symbols, 
constituting  the  distinctive  achievement  of  human  groups, 
including  their  embodiments  in  artifacts;  the  essential 
core  of  culture  consists  of  traditional  (i.e., 
historically  derived  and  selected)  ideas  and  especially 
their  attached  values;  culture  systems  may,  on  the  one 
hand,  be  considered  as  products  of  action,  on  the  other  as 
conditioning  elements  of  further  action. 

Regardless  of  the  view  one  chooses  to  believe,  the  fact  that 
group  culture  exists  is  undeniable.  This  culture  defines  the 
who,  what,  where,  why,  and  how  of  the  group  (Aronoff  and 
Baskin,  1980,  p.  58) . 

As  previously  stated,  culture  arises  from  individuals 
interacting  as  a  group.  To  illustrate  the  group  process,  one 
can  think  of  the  process  as  a  play.  Within  this  group,  each 
individual  will  play  a  certain  role.  Assignment  of  each 
member  into  their  individual  roles  is  delineated  by  the 
group's  culture  (Cooper  and  Payne,  1981,  pp.  59-71).  It  is 
also  the  culture  that  "scripts"  the  roles  of  each  the  actors 
or  participants  against  a  common  backdrop. 

Group  culture  can  be  viewed  as  the  ordinary  behavior  or 
the  norm  under  which  a  group  functions.  It  is  assxuned, 
e3q>ected,  and  what  is  normally  performed  (Greenbaum  and  Kyng, 
1991,  pp.  121-126)  .  The  formulation  of  this  day-to-day 
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routine  results  from  the  internal  dyncunics  exhibited  by  the 
group  members  as  well  as  the  group's  position  in  the  fosrmal 
and  informal  organizational  structure  (Cooper  and  Payne,  1981, 
p.  96). 

Remembering  that  groups  are  comprised  of  individuals  who 
must  constantly  communicate  with  one  another,  it  is  important 
to  state  a  major  barrier  to  productive  interpersonal 
communications.  This  major  barrier  within  all  interpersonal 
communications  is  the  psychological  aspect  of  language.  These 
siibtle  nuances  of  emotion  are  added  to  the  common  semantics  of 
language  combined  to  portray  unique  messages.  Therefore,  in 
order  to  understand  the  message  being  conveyed  the  receiver 
must  strive  to  listen  to  what  the  sender  means  rather  than 
what  he  says  (Fellows,  1964,  p.  28). 

One  may  ask  how  these  sxibtleties  of  culture  relate  to 
design  rationale.  As  previously  stated,  artifacts  are  the 
most  common  outcome  of  design  rationale;  through  the 
examination  of  these  artifacts,  researchers  and  designers 
endeavor  to  understand  the  design  rationale  that  produced  such 
an  outcome.  However,  "meanings  do  not... exist  in  artifacts, 
symbols,  or  practices. . .they  are  assigned. . .by  people  who 
perceive  and  interpret  their  content  and  context"  (Smircich, 
1983,  pp.  160-172)  .  To  interpret  accurately  the  perception  of 
the  group  which  created  the  artifact,  one  must  understand  that 
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group's  culture.  As  Greenbaum  and  Kyng  (1991,  p.  125)  pointed 
out  that  "cultural  manifestations  (artifacts)  are  easy  to 
obtain  but  difficult  to  interpret  because  they  are  eunbiguous 
and  may  hold  multiple  meanings  and  understandings. "  Again,  it 
is  the  understanding  of  group  culture  that  will  facilitate  and 
allow  this  interpretation. 

In  attempting  to  understand  group  culture,  one  will 
normally  try  to  find  a  common  reference.  This  reference  may 
easily  be  one's  personal  background  or  knowledge.  So,  instead 
of  looking  for  the  peculiarities,  one  is  really  looking  for 
similarities.  As  Geertz  (1973,  p.  14)  wrote  "understanding  a 
people's  culture  exposes  their  normalness  without  reducing 
their  particularity." 

To  understand  the  group  process,  one  must  first  understand 
the  underlying  communications  between  individuals  or  groups  in 
the  design  process.  The  complex  merging  of  individual  and 
group  communications  is  the  foundation  of  group  culture.  It 
is  upon  this  culture  that  the  everyday  processes  are  formed. 
In  the  context  of  design  rationale,  the  type  of  group  process 
of  primary  importance  is  group  deliberations;  as  explained  in 
Chapter  II,  design  rationale  is  the  outcome  of  group 
deliberations . 

When  designing  or  choosing  a  tool,  architecture,  or  system 
to  capture  design  rationale,  one  must  remain  mindful  of  the 
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communications  aspect  of  the  design  process.  Singly  capturing 
the  design  rationale,  or  the  end  product  of  the  process  may 
not  be  as  helpful  as  capturing  all  the  communications  elements 
surrounding  the  design  rationale  which  lead  to  that  end 
product.  Current  research  will  be  eled>orated  upon  in  Chapter 
IV  which  highlights  the  need  for  capturing  communications  as 
well  as  design  rationale. 
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ZV.  DESIGN  SATZOKALS  CAPTDSB 


Methodology  can  be  defined  as  "a  collection  of  procedures, 
techniques,  tools,  and  documentation  aids  which  will  help  the 
systems  developers  in  their  efforts  to  inclement  a  new 
information  system"  (Avison  and  Fitzgerald,  1988,  p.4) .  A 
mechanism  to  capture  critical  aspects  of  the  design  process  is 
an  inqportant  choice  to  be  made  by  the  designers;  how  they 
choose  to  capture  the  execution  and  any  reuse  of  the  design 
can  be  just  as  crucial  as  what  they  design. 

Mechanisms  providing  a  clear  record  of  the  employment  of 
a  design  methodology  is  a  critical  component  of  an  effective 
design  process.  The  objective  of  such  a  mechanism  is  to 
accurately  and  systematically  record  all  phases  of  the  design 
process,  to.  assist  in  the  tracking  of  costs  and  time 
requirements,  foster  the  development  of  a  user  friendly,  well 
documented  product,  euid  allow  for  adaptability  to  change  not 
only  during  the  development  stages  of  the  design  but  also 
throughout  the  life  cycle  of  the  system. 

A  variety  of  systems  have  been  developed  in  recent  years 
that  aim  at  supporting  the  capture  and  reuse  of  design  process 
information.  Some  of  these  tools  provided  are  based  on 
information  models  that  represent  design  rationale 
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information,  while  others  focus  on  capturing  group 
communication  aspects  of  the  design  process. 

We  review  some  of  the  most  advanced  systems  discussed  in 
the  literature  in  order  to  understand  the  salient  components 
of  a  conprehensive  model  for  representing  design  rationale 
information,  as  well  as  identifying  potential  technologies 
that  could  be  used  to  support  its  capture  and  use. 
Descriptions  of  the  research  methodology  employed  in  the 
development  of  these  systems  is  also  provided  to  illustrated 
the  various  methodologies  that  need  to  be  employed  to  fully 
understand  the  group  design  process. 

JL.  TANG 

John  C.  Tang's  dissertation  work  on  Listing,  Drawing  euid 
Gesturing  in  Design;  A  Study  of  the  Use  of  Shared  Workspaces 
by  Design  Teams  in  the  Department  of  Mechanical  Engineering  at 
Stanford  University  investigates  whether  "the  needs  of  a  group 
using  a  tool  colledsoratively,  are  different  from  those  of  an 
individual  user,  and  these  differences  should  be  reflected  in 
the  design  of  the  technology"  (Tang,  1991,  p.l43) .  In  order 
to  accurately  assess  these  needs,  Tang  conducted  a  series  of 
video  taped  sessions  of  groups  designing  various  products. 
The  outcome  of  these  sessions  would  enable  the  understanding 
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of  the  design  process  and  identification  of  opportunities  to 
support  group  design  practices. 

In  any  research  project,  researchers  must  first  identify 
a  methodology  upon  which  to  base  their  research.  Analytical 
methods  commonly  utilized  to  collect  data  Include 
experimental,  protocol  and  interaction  analysis. 

In  the  experimental  method,  studies  are  conducted  in  a 
controlled  environment  such  as  a  laboratory  setting.  Normally 
two  groups  are  set  up  for  the  experiment:  a  control  group  euid 
the  experimental  group.  The  experimental  group  is  subjected 
to  preset  conditions  which  are  under  study.  Analysis  of  the 
differences  between  the  two  groups  allows  researchers  to 
determine  the  effects  of  the  preset  factors  and  to  judge 
whether  they  were  a  result  of  the  experiment  or  some  other 
existing  condition. 

When  the  factors  being  studied  involve  group  interactions 
"the  validity  of  an  experimental  approach  involving  human 
activity  is  reliant  upon  the  ability  to; 

•  manipulate  the  behavior  of  the  participants  to  construct 
different  conditions, 

•  accurately  measure  the  outcome  of  each  condition  for 
con^arison, 

•  collect  a  sufficient  semqple  size  of  repeatable  activity  to 
validate  thi-;  results  and  condensate  for  individual 
variation"  (T^ng,  1989,  p.  46). 
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"Team  design  work  is  a  rich  activity  that  does  not  lend  itself 
to  conventional  experimental  methods  of  systematic  study” 
(Tang,  1989,  p.  45) . 

The  basic  methodology  en^loyed  in  protocol  analysis  is  the 
verbalization  of  thought  patterns  by  the  participemt  during 
some  predefined  task.  Subjects  are  asked  to  think  aloud  while 
working  on  the  task.  These  deliberations  are  captured  by  the 
researchers  in  the  form  of  video  or  audiotape  for  later 
analysis . 

Protocol  analysis  is  appropriate  when  studying  an 
individual,  but  its  appropriateness  in  groups  is  questionable. 
Asking  participants  to  verbalize  all  their  thoughts  could 
disrupt  the  group  process  and  stifle  creativity. 

Interactive  analysis  examines  the  details  of  human 
interaction  in  groups  and  is  the  main  thrust  of  Tang's 
research  involving  the  use  of  gestures  in  the  design  process. 

Tang's  interaction  analysis  approach  emulates  a 
qualitative  analysis  method  commonly  used  in  social  sciences. 
In  Tang's  interaction  analysis,  subjects  were  unobtrusively 
observed  in  a  natural  working  environment.  Video  and  audio 
tapes  of  the  sessions,  combined  with  the  actual  artifacts 
produced,  are  utilized  to  capture  all  interactive  processes 
between  group  members. 
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Groups  of  three  or  four  individuals  are  involved  in 
conceptual  design  tasks.  The  sessions  last  between  one  to  one 
auad  one-half  hours,  with  the  actual  duration  at  the  discretion 
of  the  group.  Two  video  cameras  are  set  up  to  observe  the 
group's  problem  solving  process.  These  stationary  cameras  are 
mounted  on  a  wall  in  a  non- intrusive  manner  such  as  not  to 
distract  the  group  dynamic  process.  The  use  of  two  passive 
cameras  is  chosen  over  a  manned  camera  because  it  is  believed 
to  be  less  distracting  to  the  participants.  One  camera 
captures  the  group  interactions  from  a  distance,  while  the 
other  is  centered  to%^rds  the  middle  of  the  working  space  to 
capture  hauid  gestures,  drawing,  euid  listing.  To  conqplement 
the  recording  process  and  later  tremscription,  an  audio  tape 
is  made  of  each  session. 

Each  session  is  initiated  with  a  briefing  given  to  all 
participants  by  the  experimenter.  This  brief  covered  the 
basic  task  which  each  group  would  perform.  Afterwards  the 
experimenter  observes  the  process  in  an  adjoining  room  via  the 
recording  equipment.  Following  each  working  session  an 
informal  debrief,  facilitated  by  the  e^qperimenter,  is 
conducted  to  capture  the  initial  feelings  about  the  group 
experience  from  each  participant's  point  of  view. 


Initial  analysis  of  the  data  is  acccmqplished  by  studying 
the  video  tapes  and  Involves: 

•  becoming  familiar  with  the  data, 

•  developing  a  working  representation  of  the  data  for 
analysis, 

•  abstracting  observations  from  the  data  (Tang,  1989,  p.  56) 

Familiarity  is  accon^lished  by  making  a  transcript  of  the 
video  and  audio  tapes.  Utilization  of  the  NoteCarda,  a 
hypertext  system,  enables  the  e3q>erimenter  to  catalogue  the 
data  in  a  user  friendly  manner.  Notecarda  is  a  transcription 
system  which  can  be  used  to  brecdc  down  the  data  (or 
conversation)  into  segments.  These  segments  contain  an  idea 
or  single  activity  which  is  typically  less  than  one  minute  in 
length  and  involve  three  to  seven  conversational  turns  by  the 
participants.  The  cards  are  then  linked  by  theme  and  ordered 
in  a  chronological  manner.  Tang  utilized  Notecarda  to 
catalogue  ideas  and  Identify  reoccurring  activities. 

Interactions  of  the  group,  as  well  as  the  artifacts 
produced,  comprise  the  workspace  activity  which  is  subdivided 
into  three  main  dimensions:  the  first  being  the  conposition 
and  the  capabilities  of  the  workspace  itself;  secondly,  the 
kind  of  task  being  performed;  and  finally,  the  working 
dynamics  of  the  group.  Conqpositlon  describes  the  materials 


available  to  the  participants  such  as  drawing  paper,  chalk 
boards,  etc.  while  the  capeJalllty  of  the  particular 
con^osition  describes  the  utilization  level  of  the  material 
itself.  For  Instance,  the  utilization  of  a  large  piece  of 
drawing  paper  which  provides  a  drawing  surface  useed^le  by  more 
than  one  participant  would  differ  from  that  of  a  single  sheet 
of  paper  upon  which  only  an  individual  could  focus. 

The  category,  kind  of  tasks,  represents  the  nature  of  the 
task  being  performed  such  as  graphics,  textual,  or  Interactive 
skills.  Length  of  time  and  stages  of  development  are  major 
coiq>onents  of  the  activity  which  are  categorized  by  the  kind 
of  task. 

The  last  category,  working  dyneunics,  excunines  interactions 
and  behavioral  patterns  displayed  by  group  members  during  the 
performance  of  the  task. 

The  framework  that  captured  the  dimensions  of  workspace 
activity  "lays  out  relationships  between  actions  that  occur  in 
the  workspace,  and  functions  that  are  accomplished  through 
those  actions"  (Tang,  1989,  p.  67>.  Accordingly,  all  group 
activities  are  broken  down  into  the  components  of  actions  and 
functions.  Actions  are  described  by  either  List,  Draw,  or 
Gesture  activities  while  functions  are  described  by  Store 
Information,  Espress  Ideas,  or  Mediate  Interaction.  A  matrix, 
designed  with  functions  being  the  row  indicator  and  actions, 
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serves  as  the  column  indicator.  Within  the  matrix,  four 
aspects  of  an  interaction  are  highlighted:  conventional  view, 
gestural  expression,  ej^ressing  ideas  and  mediating 
interaction.  This  framework  enables  the  esqperimenter  to 
describe  Interaction  in  overlapping  methods  which  esqpands  the 
conventional  views  previously  believed  to  solely  describe 
group  work.  "This  exercise  not  only  led  to  a  deeper 
fsutiiliarity  with  the  data,  but  also  helped  focus  the  analysis 
on  trends  that  became  apparent  in  the  data"  (Tang,  1991, 
p.  149) . 

Categoriration  of  data  is  acconqplished  through 
solicitation  of  various  perspectives.  By  incorporating  the 
inputs  gathered  from  multiple  sources  such  as  the 
participants,  engineers,  software  designers,  etc.  It  is  hoped 
that  the  design  team  will  form  a  global  view  of  the  data. 
This  solicitation  takes  place  in  meetings  in  which  the 
participants  vary. 

Studying  group  processes  encd^les  the  identification  and 
capture  of  many  workspace  activities  that  mediate  the  groups 
colled)orative  actions  which  are  not  normally  captured  in  the 
artifacts. 
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B.  DBDAL 


Researchers  from  Stanford  University  and  NASA  Ames 
Research  Center  have  developed  an  Electronic  Design  Notebook 
as  a  part  of  a  design  reuse  assistance  product  called  Dedal. 
The  goal  of  their  research  is  to  be  aible  to  capture  design 
information  during  the  conceptual  design  phase  in  engineering 
design  for  later  reuse. 

Researchers  are  concerned  with  the  capture  of  conceptual 
design  information  in  the  least  intrusive  way.  The  use  of 
multimedia,  such  as  video,  audio,  text  and  graphics  aids,  has 
been  selected  for  this  reason.  Because  of  the  overwhelming 
amount  of  information  that  could  be  produced,  the  team  needed 
a  way  to  categorize  the  data  to  facilitate  easy  retrieval  as 
needed.  An  indexing  system  utilizing  a  query  based  language 
has  been  developed  for  this  purpose.  The  main  goals  of  the 
language  are  to  provide  ease  of  use  and  to  reduce  the  eunount 
of  redundancy  in  the  data  collection  and  retrieval  process. 

The  development  of  the  Electronic  Design  Notebook  is  the 
first  step  in  achieving  a  reuse  system.  The  Notebook  which 
could  be  carried  by  the  designer  has  been  created  to  assist  in 
the  capture  of  technical  and  graphic  documents  as  well  as 
information  edsout  the  designer's  thinking  process.  A  smart 
work  surface  that  consists  of  a  word  processor,  graphics 


30 


Interface,  and  Indexing  capabilities  is  provided  at  the 
discretion  of  the  designer. 

Organization  of  the  data  to  facilitate  reuse  involves  the 
transformation  of  data  into  a  format  usedsle  by  a  query  based 
retrieval  system.  This  data  %iras  indexed  by  the  designer 
during  the  capture  stage  using  key  ideas  (tagged  words)  which 
would  later  be  utilized  in  its  retrieval.  A  major  problem 
with  the  Notebook  was  the  con^lexity  of  the  data  retrieval 
process . 

Dedal  is  the  progressive  extension  of  the  Notebook. 
Dedal,  like  many  other  generic  design  rationale  tools,  is  a 
"system  that  uses  (a  language)  to: 

•  enodjle  the  description  of  the  design  record  and  content, 

•  help  engineers  formulate  questions  (concerning  the  project 

under  design) , 

•  select  appropriate  records  in  answer  to  a  question" 
(Baudin,  et  al.,  1992,  p.  702). 

One  of  the  main  strengths  of  Dedal  is  its  language  and 
indexing  system.  It  has  been  developed  to  be  primarily  used 
during  mechanical  engineering  design  processes  and  its 
applicability  in  other  design  fields  such  as  software 
engineering  has  not  yet  been  explored. 
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Dedal  was  designed  to  "describe  the  content  and  form  of 
design  records  such  as  meeting  summaries,  pages  of  an 
electronic  notebook,  technical  reports  and  videotaped 
conversations  between  am  expert  designer  auid  a  novice” 
(Baudin,  et  al.,  1992,  p.  702).  Once  this  information  is 
captured,  it  is  the  responsibility  of  Dedal  to  format  it  in 
such  a  way  as  to  facilitate  reuse.  To  ensure  this,  the 
language  of  Dedal  had  to  represent  primitives  to  enconqpass  the 
content  of  design  record,  including  the  design  process,  emd 
form  of  the  design  activities.  The  specifications  document  is 
an  exait^le  of  the  "content"  or  purpose  of  a  record.  The 
design  process  feature  captures  all  discussions  which  take 
place  regardless  of  whether  the  option  being  discussed  was 
accepted  or  rejected.  The  "form"  of  the  design  information  is 
made  up  of  the  level  of  detail  of  that  Individual  piece  of 
information  such  as  global  view  and  medium  in  which  it  is 
portrayed  such  as  textual  or  graphical  representation. 

Retrieval  of  indexed  data  is  facilitated  by  heuristics 
used  in  querying  the  datcdsase  for  answers  to  specific 
C[uestions  posed  by  the  designers  and  engineers.  These 
heuristics  are  required  to  address  "two  issues  that  (made)  the 
retrieval  of  design  information  especially  difficult; 


(1)  the  (design)  concepts  evolve  over  time  and 

(2)  design  concepts  are  closely  interrelated”  (Baudin,  Baya, 
and  Gevins,  unpublished,  pp.  6-7) . 


CcMi^leted  queries  are  matched  with  record  descriptions  in 
order  to  determine  whether  relationships  exist  between  the 
queries  and  the  concepts  in  the  model. 

Indexing  patterns  are  formatted  in  the  following 
categories:  information,  topic,  subject,  level  of  detail,  and 
medium,  in  the  form  of  information  about  topic  (T)  regarding 
subject  (S)  with  level  of  detail  (L)  using  medium  (M)  .  The 
following  are  the  options  under  each  category: 


Topics 

strategy 

reference 

description 

location 

function 

operation 

dependency 


Subject - 

Class 

assembly 

con^onent 

connection 

feature 

design - 

concept 


text 

picture 

schematic 

photo 

video 

tcd^le 

equation 


Levels  of 
Detail 
conceptual 
configur¬ 
ation 
detailed 


The  above  voccUaulary  may  be  expanded  to  accommodate  specific 
aspects  associated  with  any  design  projects. 

Once  the  designer  has  formulated  the  c[uestion  or  query  for 
the  data  retrieval,  the  indexing  patterns  are  used  as  the 
basis  for  the  retrieval  system.  If  a  match  is  made.  Dedal 
returns  a  set  of  references  to  the  user.  If  any  of  the 
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references  are  availcQsle  on-line,  then  the  user  could  access 
them  immediately.  If  a  match  is  not  found,  then  Dedal  goes 
through  a  set  of  heuristics  to  "loosen"  the  match. 

Heuristics  are  categorized  into  two  classes:  retrieval 
and  ordering.  The  retrieval  heuristics  select  the  indexing 
patterns  which  relate  to  the  query  being  used.  The  ordering 
heuristics  define  how  to  order  the  references  being  selected. 

The  retrieval  heuristics  are  further  divided  into  two 
types:  proximity  and  causal  relations.  Proximity  heuristics 
look  for  areas  of  related  information  and  assumes  needed  data 
will  be  located  near  these  regions.  Causal  heuristics  look 
for  dependencies  among  the  attributes  of  the  requested  data. 

If  the  heuristic  match  is  found  to  be  reliable  then  index 
acquisition  can  be  utilized  to  create  new  indices.  "The  new 
indices  created  are  expected  to  increase  the  precision  and 
recall  of  the  retrieval . "  This  strategy  can  be  termed 
C[uestion-based  acquisition.  Effectiveness  of  new  indices  are 
rated  by  reusedDility,  relevance,  and  context  independence  in 
future  retrievals. 

The  developers  of  Dedal  have  presented  a  method  for  the 
intelligent  indexing  and  retrieval  of  design  rationale 
information.  They  have  utilized  the  talents  of  knowledge 
engineers  and  mechanical  engineers  to  help  with  the  initial 
indexing  of  vast  amounts  of  data.  From  this  process  they 
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continue  to  develop  a  language  which  encdsled  the  retrieval  of 
the  information.  By  utilizing  custom  heuristics,  the 
retrieval  mechanism  is  continually  refined. 

The  Dedal  tool,  as  presented  by  the  researchers,  is 
expandable,  euid  therefore,  should  allow  possible 
inplementation  in  other  fields  and  applications.  We  believe 
Dedal  may  be  Incorporated  into  and  enhance  other  capture 
mechcmlsms  by  tailoring  the  language  to  meet  specific 
applications  addressed  in  those  tools. 

C.  CONVERSATIONBUILDER 

ConversationBuilder  was  designed  by  the  Delta  Group  as 
part  of  ongoing  research  at  the  Human- Computer  Interaction 
LeJaoratory  at  the  University  of  Illinois.  Their  approach  to 
the  design  process  is  centered  around  the  communications 
aspect  of  group  interactivity,  namely  conversations. 

The  creators  of  ConversationBuilder  observe  that  humans 
function  in  distinct  thinking  modes,  some  of  which  require 
conscious  thought  and  others  do  not.  Conversations  arise  when 
one  wants  to  convey  part  of  their  subconscious  thoughts  to 
another  or  wants  to  change  another's  thought  patterns. 
Specifically,  "a  conversation  is  a  structured  sequence  of 
linguistic  acts  which: 
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•  serves  a  medium  for  communication, 

•  facilitates  recovery  from  breakdown, 

•  provides  synchronization  between  the  participants, 

•  is  the  mechanism  for  manipulating  the  specification" 

(Carroll,  1992,  pp.  17-18). 

However,  the  subject  or  function  around  which  the  conversation 
centers  commonly  changes  during  the  conversation  itself. 

The  goal  of  ConversationBuilder  is  to  accurately  and 
systematically  capture  all  the  nuances  of  the  conversations 
shared  between  designers.  In  order  to  accomplish  this  task, 
multiple  conversations  would  take  place  at  the  same  time,  or 
in  parallel  and  some  mechanism  would  have  to  be  provided  to 
capture  and  later  categorize  these  conversations.  As  the 
number  of  designers  involved  in  any  one  conversation 
increases,  so  does  the  possibility  for  an  increase  in  the 
number  of  subjects  into  which  they  simultaneously  delve.  This 
adds  yet  another  corrplexity  to  the  design  of 
ConversationBuilder . 

The  actual  software  conponents  which  comprise 
ConversationBuilder  are  the  Message  Bus,  Conversation 
Processor,  and  User  Interface  Suite.  A  conversation  is 
started  with  a  message  sent  from  the  user  to  the  Message  Bus. 
The  message  is  comprised  of  a  header,  made  up  of  a  tag  and 
domain  address.  An  exanple  of  a  tag  is  "status"  of  a  message 
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such  as  "available”  or  "busy."  The  domain  address  may  combine 
one  or  more  recipients.  "ConversationBuilder  operates  by 
components  sending  messages  to  each  other  over  the  Message 
Bus.  The  Conversation  Processor  operates  as  a  central 
transaction  processor.  Users  request  transactions  by 
activating  display  objects  in  their  user  interfaces"  (Carroll, 
1992,  p.  28) . 

The  Delta  group  has  developed  a  bank  transaction  center 
scenario  j  illustrate  the  functionality  of 
ConversationBuilder.  The  cycle  begins  with  "Wait  for 
Customer."  At  this  point  a  user  or  "customer”  initiates  a 
request  to  the  system  or  "teller".  A  request  consists  of 
deposits,  withdrawals,  and  inquiries  from  the  customers  on  a 
particular  account.  Conversations  between  the  customer  and 
teller  revolve  aroxind  granting  and  denying  these  requests. 
Only  one  rec[uest  and  one  customer  is  allowed  within  the  system 
at  one  time.  Customers  not  being  served  must  wait  for  the 
"Wait  for  Customer"  status  to  indicate  that  the  teller  is  free 
to  take  their  request.  Each  request  results  in  the  creation 
of  a  transaction  record  which  is  stored  in  a  database.  A 
hypertext  module  consisting  of  nodes  or  transaction  records 
and  links  or  relations  between  records  is  also  created. 
Chronology  of  the  conversation  is  maintained  by  the  system  to 
ensure  accuracy  of  the  account  transactions.  Distinct  pieces 
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of  dialog  from  the  conversations  are  referred  to  as  utterances 
while  the  entire  conversation  is  an  instance  of  a  particular 
class  or  protocol.  Action  spaces  result  from  the  input  of 
utteramces  to  the  Conversation  Processor.  "The  parts  of  a 
conversation  are: 


•  an  instance  of  the  protocol  class 

•  a  set  of  participants 

•  an  action  space  for  each  participant”  (Carroll,  1992, 

p.  168) . 


ConversationBuilder  was  intended  to  be  used  to  capture 
conversations  in  the  design  process.  ConversationBuilder  did 
not  prove  to  be  a  useable  system  as  stated  by  Carroll  (1992, 

p.  262) : 


(It)  supports  design  in  a  poor  to  mediocre  way.  It 
cannot  be  considered  a  "good”  design  support  system  in  the 
sense  of  providing  a  coitplete  and  design  support 
environment.  The  system  has  a  nvimber  of  inadequacies  that 
prevent  the  generation  of  smoothly  functioning  design 
support  applications. 


One  particular  inadequacy  centered  around  its  inability  to 
support  commitments  in  conversation.  In  other  words,  it  could 
not  provide  a  strong  mechanism  to  track  whether  tasklngs  were 
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completed  by  those  individuals  who  indicated  a  "commitment”  to 
them. 

Aside  from  ConversationBuilder' s  shortcomings,  Fischer 
asserts  his  belief  that  his  research  in  the  formulation  of 
ConversationBuilder  provides  an  excellent  theoretical  basis 
for  further  research  in  this  area.  Since  conversations  are 
the  center  of  all  deliberations,  the  study  of 
ConversationBuilder  has  great  relevance  to  the  capture  and 
reuse  of  design  rationale. 

D.  NBTNOSK-BYDRA 

As  the  size  and  complexity  of  design  projects  grow,  the 
number  of  people  involved  in  the  project  correspondingly 
increases.  Although  the  focus  of  many  individuals'  work  may 
be  the  same  project,  each  may  work  at  different  locations  or 
at  different  points  in  time.  In  both  cases  some  form  of 
collaboration  would  benefit  the  design  process  even  though 
face-to-face  collaboration  may  prove  difficult  or  perhaps  not 
feasible.  The  designers  of  NETWORK-HYDRA  recognized  the  need 
to  support  collcd)oration  cunong  members  of  design  teams  when 
direct  communications  between  them  were  inpossible  or 
inpractical. 

NETWORK-HYDRA  provides  a  mechanism  that  would  allow  an 
individual  to  work  independently,  yet  be  alerted  when  any 


39 


aspect  of  their  work  had  scnne  Inpact  on  others'  designs.  By 
alerting  the  designer  of  conflicts  or  correlations  of  their 
work  with  data  in  the  system,  NETWORK-HYDRA  would  allow  the 
designers  to  assess  the  impact  of  their  work  on  the  overall 
project,  thus  enriching  the  individual  designers' 
understauiding  of  how  other  designers  work  in  the  project  is 
relevant  to  their  own.  By  functioning  in  this  manner,  the 
system  "could  effectively  create  virtual  cooperation  between 
all  designers  who  ever  worked  on  the  project"  (Fischer,  et 
al.,  1992,  p.  285). 

The  work  conducted  by  researchers  at  the  University  of 
Colorado,  University  of  California,  Irvine,  and  GMD, 
Darmstadt,  Germany  have  three  major  goals  in  the  development 
of  NETWORK -HYDRA;  integration  of  collcd>oration  efforts; 
integration  of  construction,  reuse,  and  specifications;  and 
support  of  the  creation  of  design  rationale. 

The  largest  problem  that  the  researchers  face  in  the 
capture  of  design  rationale  information  is  motivating  the 
designers  to  impart  it.  Unless  the  individual  designer  feels 
there  is  something  to  gain  from  the  capture,  it  is  unlikely 
that  the  individual  would  be  willing  to  aid  in  the  process. 
With  this  in  mind,  the  research  team  has  developed  the  idea  of 
creating  a  "seed"  which  contained  a  skeleton  of  a  design 
environment  to  which  the  designers  could  input  information. 


Vast  amoiints  of  infoinnation  are  commonly  required  in  a 
single  project  and  it  is  unlikely  that  one  person  would  have 
the  esqpertise  to  utilize  or  even  the  need  for  all  the  data 
available.  However,  having  such  data  readily  available  to 
designers  as  they  require  it  could  facilitate  the  design 
activity.  Two  key  functionalities  of  the  NETWORK-HYDRA  system 
are  the  facilities  to  allow  designers  to  retrieve  the  material 
relevant  to  their  area  of  design  emd  to  alert  them  to  problems 
associated  with  their  individual  task  which  may  conflict  with 
others'  work.  The  information  which  would  allow  these 
functionalities  requires  the  system  to  integrate  collaborative 
work  as  well  as  Individual  efforts. 

The  design  process  as  seen  by  the  research  teeun  is 
ccmiprised  of  two  states:  action  and  reflection.  They  view 
the  designer  as  typically  working  in  a  nonreflective  manner 
until  a  breakdown  or  problem  occurred.  At  this  time,  the 
designer's  process  changes  to  a  reflective  state  in  order  to 
repair  the  breakdown.  Once  a  "fix”  is  achieved,  either  good 
or  bad,  the  process  returns  to  the  nonreflective  state.  These 
are  referred  to  as  construction  (action)  and  argiimentation 
(reflection) .  To  integrate  the  two,  NETWORK-HYDRA  alerts  the 
designer  when  a  breadcdown  occurs. 

To  capture  these  states,  a  hypermedia  system  is  utilized 
because  it  allows  for  a  multiplicity  of  connections  and  offers 
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the  avalleUsility  of  media  other  than  text.  The  gIBIS  model  is 
the  basis  for  the  preliminary  model  incorporating  the 
researchers'  own  language,  PHI  (Procedural  Hierarchy  of 
Issues) .  PHI  focuses  of  the  dependency  relationships  between 
issues  and  how  interdependencies  affect  the  system  as  a  whole. 

The  following  exanple  on  the  construction  of  a  network 
illustrates  the  functionalities  of  the  NETWORK-HYDRA 
architecture.  Network  systems  are  normally  evolutionary  in 
nature;  this  is  due  to  changing  configuration  requirements 
necessitated  by  varying  connection  needs  and  changes  in 
hardware  and  software  develo^mient.  with  most  network  changes 
commonly  occurring  over  a  long-term  basis,  managers  of  the 
system  need  to  be  aware  of  past  decisions  and  problems 
associated  with  any  changes  as  well  as  current  requirements. 
As  tuxnover  of  personnel  can  occur  during  this  time,  a  system 
to  capture  this  information  is  needed  so  the  system  is  not 
dependent  solely  on  the  knowledge  of  its  users  and/or 
designers . 

A  domain  knowledge  base  which  consists  of  design  parts, 
rules  and  discussions  was  constructed  from  an  existing  network 
system,  is  used  as  the  Initial  "seed”  prototype  for  the  hyper¬ 
media  system. 

Since  design  projects  tend  to  evolve  over  time,  the  system 
is  designed  to  provide  end-user  modifiability.  "To  support 
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evolution  on  a  continual  basis,  the  people  experiencing  the 
breakdowns  are  in  the  best  position  to  do  something  about 
them"  (Fischer,  et  al.,  1992,  p.  296).  The  seed,  therefore, 
is  formulated  in  a  manner  which  allows  it  to  evolve  over  time. 
As  modifications  occur  because  of  breetkdotms  in  the  system, 
the  seed  could  accurately  reflect  these  changes. 

The  NETWORK -HYDRA  system  architecture  is  comprised  of 
the  following  con^onents: 

e  construction  kit 
e  argximentative  hypermedia 
e  specification  conponent 

•  catalog 

•  simulation  corr^onent. 

The  construction  kit  provides  a  palette  for  the  designers 
to  utilize  during  the  design  stage.  With  the  rapid  changes  in 
technology  in  mind,  the  designers  have  built  end-user 
modificUsle  palettes  to  allow  for  maximum  utilization  of 
availed)le  collcUsorative  tools. 

The  argumentative  hypertext  incorporates  PHI  as  well  as 
other  multimedia  environments.  The  primary  purpose  of  the 
hypertext  is  to  provide  the  designers  with  the  requisite 
information  needed  to  repair  a  breakdown  and  continue  with  the 
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design  process.  Hypertext  is  used  to  represent  detailed 
information  on  breakdown;  possible  issues,  answers,  and 
argumentation;  and  the  design  rationale  of  others  in  order  to 
repair  breakdowns. 

The  specification  conponent  allows  designers  to  input 
system  requirements  and  constraints  associated  with  the  task 
to  "tailor  its  information  structures  by  filtering  out 
argvimentatlon,  critics,  and  catalog  exan^les  that  are  not 
relevant  to  the  specific  task"  (Fischer,  et  al.,  1992,  p. 
304) .  As  the  project  evolves,  changes  to  requirements  are 
incorporated  thus  refining  the  specifications  conqponent.  "In 
collcQdorative  design,  specifications  serve  to  help  coordinate 
the  work  of  group  members  by  providing  a  common  framework  in 
which  to  operate"  (Fischer,  et  al.,  1992,  p.  304).  Again,  it 
is  in^ortant  to  remember  that  changes  made  by  individual 
designers  affect  the  entire  system  and  designers  may  not 
possess  the  knowledge  about  the  entire  system  which  would 
allow  them  to  accurately  predict  the  effect  of  those 
changes . 

A  catalog  of  design  artifacts  is  readily  availcJale  to 
designers.  This  facility  provided  a  mechanism  through  which 
inclusions,  deletions,  and  modifications  could  be  made.  This 
catalog  also  serves  as  the  storage  for  designs,  design 
rationale,  and  specifications  for  later  reuse. 
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The  last  component  facilitates  simulation  of  scenarios  in 
which  "what  if"  conditions  can  be  imposed. 

Tools  provided  by  NETWORK - HYDRA  include:  a  construction 
analyzer  to  provide  a  critiquing  system  used  during  breakdown; 
a  catalog  explorer  for  use  in  searches  of  the  system;  and  an 
argumentation  illustrator  which  provides  examples  to  be  used 
by  designers  to  promote  understanding  of  the  information 
presented. 

Design  rationale  and  reuse  are  key  ingredients  to  all 
projects  in  all  stages  of  development.  This  tool  allows  for 
the  use  of  design  rationale  throughout  the  system's  life 
cycle.  Additionally,  NETWORK-HYDRA  reduces  redundancy  and 
maximizes  the  use  of  knowledge  and  skills  of  designers  by 
allowing  easy  access  to  group  memory. 

E.  gIBIS 

The  gIBIS  tool  was  developed  as  part  of  the  Design  Journal 
project  at  Microelectronic  Computertechnology  Corporation 
(MCC) .  Design  Journal  is  a  hypertext  tool  which  was  designed 
to  support  system  design  processes.  The  developers  viewed 
design  journals  as  traditional  and  nontraditional  documents 
and  aspects,  both  of  which  could  be  supported  by  their  tool. 
Traditional  aspects  include  specifications,  requirements,  and 
design  docximents.  Nontraditional  aspects  include  components 
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or  activities  which  are  not  normally  archived  as  part  of  the 
design  process  such  as  interviews,  scenarios,  notes,  sketches, 
design  decisions  and  rationale,  and  design  constraints.  In 
addition  to  supporting  both  aspects,  gIBIS  also  aimed  at 
supporting  the  "upstream  informal  processes"  which  commonly 
surround  deliberations  encompassed  in  the  formulation  of 
design  rationale. 

There  are  two  aims  in  the  research  which  led  to  the  gIBIS' 
design: 

•  understanding  the  internal  structure  of  design  decisions 
and  their  dependencies 

•  addressing  interface  problems  associated  with  indexing  and 
retrieval  of  vast  amounts  of  informal  data  (Begeman  and 
Conklin,  1980,  p.  304) . 

The  gIBIS  tool  provides  graphical  support  for  Horst 
Rittel's  Issue-Based  Information  Systems  (IBIS)  method  as 
illustrated  in  Figure  1: 
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Source  Begeman  and  Conklin,  1988,  p.  305. 


The  IBIS  method  was  based  upon  the  belief  that  the  design 
process  is  basically  a  conversation  between  stakeholders,  each 
of  which  contributes  their  concerns  and  expertise  toward  the 
resolution  of  design  issues.  All  deliberations,  whether  they 
are  in  the  form  of  problems,  questions  or  concerns  can  be 
viewed  as  an  issue.  The  addressing  or  resolution  of  issues  is 
what  Rittel  viewed  as  the  design  process.  Rittel  summarizes 
the  method  by  stating  "the  concept  of  IBIS  rests  on  the  model 
of  problem  solving  by  cooperatives  as  an  argumentative 
process"  (Kunz  and  Rittel,  1970,  p.  1) . 

The  IBIS  method  centers  around  the  articulation  of  key 
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issues  by  the  stakeholders.  Each  issue  may  have  multiple 
positions.  A  position  i.?  a  statement  or  belief  which  serves 
to  advocate  the  issue.  There  may  be  one  or  more  arguments 
which  either  support  or  object  to  a  position.  Each  issue  may 
be  the  root  of  a  tree  whose  children  are  positions ,  which  then 
may  be  parents  for  arguments.  All  of  the  nodes  are  connected 
by  links  which  state  the  particular  association  of  the  two 
nodes  being  connected.  For  example,  "supports"  or  " objects - 
to"  links  connect  arguments  to  positions.  In  employing  this 
method  "...  the  goal  of  the  discussion  is  for  each  of  the 
stakeholders  to  try  to  understand  the  specific  elements  of 
each  others'  proposals,  and  perhaps  to  persuade  others  of 
one's  viewpoint"  (Begeman  and  Conklin,  1988,  p.  305) . 

In  addition  issues,  positions,  and  arguments,  gIBIS  also 
incorporates  an  other  node.  The  purpose  of  this  node  is  to 
allow  the  user  to  escape  the  theme  upon  which  current  work  is 
centered  and  provide  the  capability  to  express  and  store 
unrelated  information.  An  additional  node  called  external  is 
available  for  the  storing  of  artifacts  such  as  documents, 
sketches,  and  code.  Extending  the  original  IBIS  model  with 
nodes,  gIBIS  attempts  to  support  both  the  design  process  and 
computer-mediated  teamwork. 


48 


The  user  interface  provided  in  the  gIBIS  tool  consists  of 
four  tiled  windows: 

•  graphical  browser 

•  structured  index 

•  control  panel 

•  inspection  window 

As  the  name  implies,  the  Graphical  Browser  provides  a 
visual  representation  of  the  nodes  and  associated  links. 
While  working  in  this  window,  the  user  is  afforded  a  global 
view  of  the  project  in  the  lower  corner  of  the  screen,  while 
the  central  part  displays  a  working  model  of  the  area  of 
interest . 

In  the  Node  Index  Window  the  user  is  shown  a  hierarchical 
view  of  the  nodes  of  the  current  IBIS  network.  This  offers 
the  user  an  additional  method  to  select  nodes  for  more  in 
depth  examination. 

The  Control  Panel  provides  functionality  through  the 
manipulation  of  buttons  such  as  "next,"  "help,"  and  "done." 
Each  button  offers  a  pull  up  menu  and  description  of  the 
function  provided. 

The  Inspection  Window  offers  a  detailed  description  of  the 
selected  node  and  its  links. 
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The  system  also  offers  two  additional  functionalities 
through  the  Tool  Configuration  Window  and  the  Query  Control 
and  Help  Window.  These  windows  assist  the  user  in  setting 
parcimeters  and  searching  for  nodes  through  the  manipulation  of 
query  based  questions. 

In  addition  to  designing  the  functionalities  previously 
mentioned,  the  design  of  gIBIS  strove  to  address  several  other 
goals  such  as  maximum  reliability,  support  of  multiple 
concurrent  users,  reasonably  good  performance,  and 
implementation  utilizing  limited  resources. 

Users  who  function  both  individually  and  in  groups  have 
reported  that  gIBIS  proves  to  be  a  useful  tool  (Begeman  and 
Conklin,  1988,  p.  323).  For  the  individual,  support  in 
focusing  thinking  on  difficult  issues  was  aided  by  the  IBIS 
framework.  In  the  group  realm,  conversations  were  supported 
by  the  enforcement  of  a  strict  framework  for  discussions. 

Even  though  the  tool  has  proven  to  be  beneficial,  users 
did  identify  the  following  shortcomings: 

•  no  specific  nodes  are  available  for  the  incorporation  of 
goals  and  requirements 

•  no  available  facility  for  providing  support  for  choosing 
among  the  various  positions  of  an  issue 

•  no  method  to  link  artifacts  to  specific  areas  within  the 
gIBIS  tool  to  facilitate  the  decision  process  (Begeman  and 
Conklin,  1988,  p.  324) . 
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An  inherent  problem  of  IBIS  identified  by  the  developers 
of  gIBIS  was  "segmentation."  Because  many  conversations  about 
design,  especially  in  the  early  stages,  are  of  the 
brainstorming  type,  identifying  well  defined  issues  may  be 
difficult.  Individuals  may  express  thoughts  which  are  vague, 
confusing  or  incomplete  and  labeling  each  of  these  as  an 
individual  issue,  when  they  are  in  reality  part  of  the  same 
issue  may  be  nonproductive.  This  type  of  behavior  may  lead  to 
premature  decisions.  If  in  their  enthusiasm  for  employing  the 
tool,  designers  are  not  aware  of  this  potential  problem,  they 
may  not  fully  explore  or  identify  the  subject  around  which  the 
issue  is  centered  before  they  specify  it.  This  phenomenon  of 
premature  labeling  may  cause  information  about  the  issue  to  be 
fragmented  or  spread  into  areas  other  than  the  issue  which 
designers  originally  intended. 

Although  the  availability  of  the  external  node  offered  a 
means  to  label  artifacts,  there  was  no  specific  functionality 
such  as  a  menu  choice  to  link  the  artifacts  to  particular 
nodes;  this  separation  limited  the  full  use  of  the  tool  to 
support  all  design  deliberations. 

F.  REMAP 

REpresentation  and  MAintenance  of  Process  knowledge 
(REMAP)  is  a  conceptual  model  designed  to  represent  design 
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rationale  and  deliberations  during  decision  making  by 
providing  a  method  to  capture  the  entire  process.  REMAP 
includes  the  IBIS  method  to  model  argumentation  processes. 


REMAP'S  central  goal  is  the  capture  of  the  entire  history 
of  the  design  process  during  all  phases  of  the  life  cycle. 
During  the  life  cycle,  numerous  artifacts  are  created,  each 
with  an  accompanying  set  of  documentation.  An  important 
component  typically  missing  from  this  docxomentation  is  the 
rationale  for  the  development  of  the  artifact. 

The  REMAP  project  is  specifically  concerned  with  capturing 
rationale  during  the  early  stages  of  the  systems  development 
process,  namely  requirements  engineering,  because  well  defined 
requirements  are  critical  to  the  development  of  high  quality 
software.  Recent  research  also  suggests  that  reusability  at 
the  requirements  stage  is  more  productive  than  at  the  coding 
level.  Availability  of  rationale  will  greatly  enhance  such 
reuse . 

Numerous  studies  have  highlighted  the  importance  of 
capturing  design  rationale  for  the  following  reasons: 

•  multi -person  teams  involve  communication  and  coordination 
between  members 

•  long-term  projects  usually  involve  changing  personnel  and 
requirements  which  result  in  miscommunication  and  loss  of 
information 
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•  critical  errors  can  result  from  lost  data  during  decision 
making  deliberations 

•  misinterpretation  and  misunderstanding  occur  in  large 
projects  over  time  involving  different  participants  at 
different  phases  of  work  (Dhar  and  Ramesh,  1992,  pp.  498- 
499)  . 


The  capture  and  reuse  of  design  rationale  is  especially 
pertinent  for  large,  complex  projects. 


As  these  projects  involve  often  large  and  complex 
problems,  creation  of  design  solutions  involves 
knowledge  that  spans  several  areas. .. .Since  no  single 
designer  possesses  all  the  knowledge  required  to 
produce  a  solution,  a  team  of  several  members  is 
typically  involved  in  a  design  task  (Dhar  and  Ramesh, 
1992,  p.  499) . 


REMAP  includes  the  IBIS  framework  discussed  in  the  earlier 
section  involving  concept  types  and  relationships: 

•  Issue:  a  problem,  concern  or  question 

•  Position:  a  solution  which  responds  to  an  issue.  Note 
that  positions  are  not  mutually  exclusive 

•  Argument:  statement  that  supports  or  objects  to  positions 
Additionally,  REMAP  incorporates: 

•  Requirement:  represent  goals  or  objectives  of  the  design 
problem 

•  Design  Object:  artifact  which  satisfies  a  requirement 

•  Decision:  result  of  deliberations  phase  concerning  issues 
discussed 

•  Assumption:  idea  taken  to  be  true  concerning  an  argument 
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•  Constraint:  restriction,  limit,  or  regulation  placed  on 
the  design  object  by  a  decision  (Dhar  and  Ramesh,  1992, 
pp.  499-500). 

Design  efforts  entail  both  individual  efforts  involving 
independent  work  and  group  problem  solving  resolving  issues 
previously  excunined  by  the  individuals.  The  REMAP  model  was 
derived  based  on  an  empirical  study  of  individual  and  groups 
of  experienced  systems  analysts  involved  in  a  requirements 
engineering  task. 

Two  types  of  experiments  were  conducted.  The  first 
involved  individual  "think  aloud"  exercises  in  which  the 
participants  were  engaged  in  a  problem  solving  design  task. 
The  second  involved  the  use  of  transcriptions  from  group 
meetings  for  requirements  engineering.  The  experiment 
required  the  participants  "to  clearly  articulate  decisions 
made  and  reasons  for  making  such  decisions"  (Dhar  and  Ramesh, 
1992,  p.  500)  .  The  REMAP  conceptual  model  resulted  from  the 
analysis  of  this  data.  IBIS  is  the  fundamental  building  block 
used  to  formulate  the  model.  Additions  to  IBIS  enable 
tailoring  the  model  to  the  systems  design  content.  Figure  2 
illustrates  the  REMAP  model : 
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Figure  2  REMAP  Model 
Source  Dhar  and  Ramesh,  1992,  p.  501. 


According  to  REMAP,  the  initial  Requirements  are  set 
during  the  early  stages  of  the  design  process.  They  represent 
the  goal  or  objective  to  be  met  by  the  designers  in  achieving 
the  Design  Object  or  artifact.  Issues  are  generated  as 
deliberations  are  conducted  concerning  the  stated  Requirements 
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and  also  as  individuals  present  problems  that  need  to  be 
resolved  before  proceeding  on  with  the  design.  "Initial 
requirements  get  refined,  modified,  and  elaborated  during  the 
deliberation  process..."  (Dhar  and  Reunesh,  1992,  p.  501). 
Issues  are  formulated  and  refined  in  a  hierarchical  manner. 

Participants  assxame  various  Positions  concerning  these 
Issues  which  are  supported  by  or  objected  to  through  the  use 
of  Arguments.  Assumptions  about  a  particular  Argument  are 
explicitly  represented.  Ultimately  a  Decision  or  set  of 
Decisions  is  reached  by  the  group  concerning  each  Issue  or  set 
of  Issues. 

REMAP  extends  IBIS  by  incorporating  the  artifacts  that  are 
resultants  of  design  deliberations.  These  artifacts  or  Design 
Objects  are  linked  to  the  decision  through  constraints  that 
are  implied,  generated,  or  led  to  by  decisions  resulting  from 
the  deliberations. 

The  prototype  software  incorporating  the  REMAP  model  is 
based  on  the  software  package  called  ConceptBase,  which 
implements  TELOS,  a  high-level  conceptual  modelling  language. 
ConceptBase  was  selected  for  its  client-server  architecture 
that  could  support  distributed  design  processes. 

REMAP  provides  facilities  for  the  construction,  querying, 
and  maintenance  of  structured  knowledge  bases  which  are  the 
building  blocks  for  capturing  and  storing  of  design  rationale. 
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The  REMAP  tool  supports  interactive  instantiation, 
querying,  and  modification  of  instances  of  REMAP  objects. 
Interactive  use  of  the  tool  facilitates  the  incremental 


acquisition  of  process  knowledge  or  design  rationale.  In 
order  to  allow  for  a  convenient  traversal  of  the  knowledge 
base  created,  a  hypertext  browsing  capability  is  provided. 
REMAP  provides  the  user  capability  to  browse,  display  and  edit 
existing  design  rationale  objects  at  any  phase  of  the  design 
process . 

REMAP,  in  contrast  to  gIBIS,  provides  primitives  such  as 
Requirements,  Decisions,  Assumptions,  Constraints ,  and  Design 
Objects.  Further,  besides  providing  an  extended  model,  REMAP 
supports  active  reasoning  with  the  design  rationale  knowledge. 
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V.  ARCHITECTURE  FOR  DESIGOI  RATIONALE  CAPTURE 


A.  OVERVIBN  OF  THE  INFORMATION  MODEL  COMPONENTS 

Primary  outputs  of  the  design  process  are  design  objects 
or  artifacts.  Current  practices  of  documentation  focus  on 
representative  outputs,  ignoring  the  processes  that  lead  to 
their  creation.  As  discussed  in  Chapter  IV,  recent  research 
has  identified  the  importance  of  capturing  the  components  of 
this  process  knowledge  known  as  design  rationale.  In  this 
research,  our  goal  is  to  identify  the  components  of  an 
information  model  for  design  rationale  and  functionalities  of 
mechanisms  to  support  the  capture  and  use  of  design  rationale 
knowledge  in  design  activities. 

This  chapter  will  discuss  the  following  basic  questions 
about  design  rationale; 

(1)  What  information  should  be  captured? 

(2)  What  mechanisms  should  be  provided  to  facilitate  capture 
and  use  of  the  information? 

We  will  answer  these  questions  by  first  exploring  what 
specific  types  of  information  should  be  captured  and  why  they 
are  relevant  to  design  rationale  and  suggest  exaunples  of  how 
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they  can  be  incorporated  into  a  design  rationale  information 
model  designed  for  the  capture  and  reuse  of  this  information. 
Where  applicable,  we  will  cite  specific  tools  or  models  which 
currently  support  such  capture  and  use.  Later,  we  will 
discuss  the  generic  functionalities  which  we  believe  should  be 
present  in  a  design  rationale  management  tool  used  to 
implement  the  design  rationale  information  model. 

B.  INFORMATION  MODEL  COMPONENTS 

The  information  model  defines  the  content  of  the  design 
rationale  to  be  captured.  Although  there  are  numerous  design 
rationale  capture  models,  such  as  gIBIS,  many  address  only 
limited  aspects  of  design  activities.  There  are  useful 
mechanisms  developed  in  other  research  that  would  aid  in  the 
capture  and  use  of  design  rationale  information,  but  they  are 
not  based  on  a  comprehensive  design  rationale  model.  In  this 
section  we  will  expound  not  only  on  what  should  be  captured  by 
an  information  model,  but  why  and  provide  examples  of  how  that 
capture  could  take  place;  we  believe  the  REMAP  model  which  we 
explored  in  Chapter  IV  offers  many  of  the  fundamental  building 
blocks  necessary  for  such  a  design  rationale  information 
model.  Instead  of  restating  all  the  component  descriptions, 
we  will  begin  by  suggesting  viewing  each  of  the  following 
REMAP  primitives:  requirement,  issue,  position,  argument. 
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assumption,  decision,  constraint,  and  design  object,  and 
various  relationships  among  them.  Our  research  has  identified 
several  other  components  that  could  be  incorporated  in  an 
information  model  that  includes  the  REMAP  model.  The 
following  section  describes  these  in  detail: 

1.  Stakeholder  -  Characteristics 

As  projects  become  more  complex  in  size  and  scope, 
design  endeavors  commonly  involve  groups  of  designers  or 
stakeholders  working  together  rather  than  single  designers 
working  independently.  Thus,  in  order  to  understand  design 
rationale  resulting  from  a  group  process,  one  must  first 
understand  the  group  itself,  the  importance  of  which  we 
expounded  upon  in  Chapter  III. 

To  gain  additional  insights  into  design  rationale  one 
should  examine  their  sources.  In  a  large  design  effort,  each 
member  of  the  group  may  have  different  interests.  For 
example,  one  may  be  a  project  manager  whose  main  objective  is 
keeping  the  project  on  schedule,  another  may  be  a  senior 
engineer  who  was  brought  into  the  project  because  of  previous 
involvement  on  a  similar  project,  yet  another  may  be  a 
customer  representative  whose  primary  goal  is  keeping  costs  to 
a  minimum.  All  of  these  members,  as  stakeholders,  will  have 
unique  perspectives  and  goals  which  could  affect  the  design 
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rationale.  Many  insights  into  design  rationale  may  be  gained 
by  the  identification  of  the  stakeholders  who  formulated  them. 

Examples  of  the  stakeholder  characteristics  that  could 


be  included  in  such  a  model  include: 

a.  JRoIe 

The  method  in  which  the  individual  stakeholders 
interact  may  also  provide  additional  insights  into  design 
rationale.  As  we  discussed  in  Chapter  III,  the  phenomenon 
referred  to  as  "group  think"  can  allow  authority  figures  to 
influence  the  group  to  make  decisions  which  may  not  be 
technically  sound.  Illustrations  of  individual  members' 
search  for  authority  figures'  approval  or  social  acceptance  is 
sometimes  reflected  in  work  habits.  Therefore,  an  explicit 
link  between  design  rationale  and  the  role  of  every 
stakeholder  who  contributed  to  it  is  an  important  component  of 
an  information  model. 

b.  Experience/Backgroimd 

Additionally,  each  stakeholder  will  bring  his  or 
her  own  personal  background  and  design  experience.  Naturally, 
experienced  designers  and  novice  designers  will  have  vastly 
different  work  habits.  For  example,  a  novice  designer  would 
most  likely  go  through  the  design  process  in  a  very  methodical 
and  step-by-step  manner,  whereas  a  more  experienced  designer 
would  probably  be  less  meticulous  and  would  be  more  prone  to 
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combine  and  delete  minor  steps  and  make  assumptions  that  are 
not  explicitly  documented.  Identification  of  the  experience 
level  and  background  of  the  stakeholder  may  improve  the 
understanding  and  the  potential  for  reuse  of  rationale. 

Another  example  of  an  experience  factor  which  may 
affect  design  rationale  is  the  stakeholder's  length  of 
involvement  in  the  project.  Those  who  have  a  longer 
association  with  the  project  will  have  more  knowledge  about 
its  idiosyncracies . 

With  changing  project  teams,  the  goals  and 
priorities  of  the  group  may  change.  Being  able  to  identify 
such  changes  can  help  identify  possible  sources  of  design 
rationale  which  embody  the  changes. 

The  people  involved  in  single  projects  are  not 
necessarily  located  in  one  area.  Ready  identification  of 
location  will  provide  clues  as  to  what  special  considerations 
were  made  to  enable  non- collocated  stakeholders  to  work  in 
conjunction  with  one  another. 

The  characteristics  described  above  are  only  some 
examples  of  "background"  information  which  could  be  captured 
as  properties  of  the  stakeholder.  Additional  varieties  of 
characteristics  such  as  their  "stake"  in  the  project  could 
also  be  captured,  based  on  the  intended  use  of  such 
information  in  design  activities. 
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2.  Gesture  -  Body  Language,  Drawing,  Listing 

Although  design  rationale  may  be  explicitly  reflected 
in  textual  artifacts,  some  of  the  communications  in  their 
formulation  cannot  be  adequately  preserved  in  a  textual 
representation.  In  the  Chapter  IV,  we  discussed  Tang's 
research  which  explored  the  importance  of  capturing  the 
gestures  that  accompany  human  communications  involved  in 
design  activities.  These  activities  include  body  language, 
listing,  and  drawing.  There  is  an  old  saying  that  "a  picture 
is  worth  a  thousand  words"  which  holds  much  relevance  in  the 
use  of  multimedia  to  capture  gestures.  Simply  having  an 
observer  take  notes  and  transcribe  them  at  a  later  date  or 
having  designers  input  textual  details  of  design  rationale 
does  not  capture  the  full  essence  of  interactions.  Further, 
such  recording  actions  may  interrupt  the  design  process. 

Passive  video  taping  could  be  a  non- intrusive  capture 
mechanism  that  would  reflect  the  multi -dimensional  activities 
of  gesturing  because  "we  lack  a  ready  descriptive  vocabulary 
for  bodily  behavior  which  could  be  captured  in  notes 
(therefore)  the  looks,  the  body  orientations,  all  of  that  is 
lost  and  probably  not  recoverable  from  memory"  (Greenbaum  and 
Kyng,  1991,  p.  79)  .  The  mechanisms  required  to  easily 
identify  and  retrieve  this  information  are  discussed  later  in 
this  chapter. 
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3.  Issue  -  Characteristics 


There  are  several  important  characteristics  of  issues 
which  need  to  be  resolved  during  the  design  process  which,  if 
captured,  would  greatly  enhance  the  usefulness  of  design 
rationale  information.  Examples  of  such  characteristics  of 
issues  include: 

a.  Time  steuqp 

Knowing  how  design  rationale  were  formulated  may 
provide  a  more  in  depth  understanding  of  the  rationale 
itself.  The  order  in  which  design  issues  were  introduced  may 
at  a  cursory  glance  appear  trivial,  however,  the  sequence  may 
be  as  important  as  the  eventual  rationale  which  was 
formulated.  Being  able  to  explore  the  existence  of  such 
sequencing  and  subsequent  correlations  would  help  in  the 
understanding  of  the  thought  patterns  employed  by  the 
designers . 

There  are  current  mechanisms  which  exist  to  capture 
such  dynamics  and  allow  replay  of  activities;  an  illustration 
is  seen  in  REMAP  which  allows  chronological  or  design 
dependency- directed  replay  of  design  rationale  information. 
Examples  of  useful  temporal  information  include  a  time  stamp 
indicating  when  the  issue  was  created  or  when  it  was  resolved. 
An  attempt  to  employ  this  type  of  information  was  detailed  in 
the  ConversationBuilder  discussion  in  Chapter  IV. 
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b.  Status 


Tracking  project  status  can  be  accomplished  by 
identifying  "open"  issues,  or  issues  that  have  not  been 
resolved.  The  gIBIS  tool  presently  offers  the  ability  to  mark 
outstanding  issues  and  has  a  query  facility  to  retrieve  them, 
c.  Prioritization  and  Resource  Eiqyended 

Once  the  outstanding  issues  have  been  identified, 
additional  capabilities  should  exist  to  allow  for  the 
prioritization  of  the  tasks  which  would  resolve  open  issues. 
Examples  of  factors  which  could  influence  the  prioritization 
are  criticality  or  complexity  of  an  issue.  For  example, 
knowing  ninety  hours  had  been  spent  on  issue  "A"  and  twenty 
hours  on  issue  "B"  would  provide  a  designer  or  project  manager 
with  more  information  than  just  knowing  some  time  had  been 
spent  on  issue  "A, "  and  some  time  had  been  spent  on  issue  "B, " 
and  both  are  currently  unresolved.  Capture  of  design 
rationale  related  statistics  may  provide  additional  insight 
because  factors  like  hours  spent  may  be  an  indication  of  the 
complexity  of  the  task  which  would  help  managers  in 
prioritization  of  work.  Other  management  functions  such  as 
tracking  of  issues  to  assess  how  to  allocate  resources  such  as 
man  hours  can  also  be  aided  by  such  information. 
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d.  Subject  Area 

The  typical  project  manager  continually  deals  with 
outstanding  activities,  but  having  the  capability  to  define 
the  subject  area  of  the  issue  will  enable  categorization  or 
selective  retrieval  of  unique  issues  or  groups  of  issues. 
Such  information  could  assist  in  gaining  insight  as  to  why  a 
class  of  issues  remains  unresolved.  The  design  rationale  of 
the  unresolved  issues  may  also  indicate  trends  in  problems 
which  hinder  issue  resolution  or  may  function  as  indicators 
for  upcoming  or  future  problems  if  certain  types  of  issues 
pose  recurring  difficulties.  Functionalities  that  provide 
tracking  of  issues  should  possess  a  flagging  mechanism  that 
allows  the  user  to  identify,  compute,  and  correlate  statistics 
on  outstanding  issues  by  subject  areas.  NETWORK-HYDRA 
currently  possesses  such  flagging  mechanisms  and  allows  for 
the  identification  of  unresolved  issues. 

4.  Project  Dictionary 

The  design  rationale  information  model  should  include 
a  tailorable  project  dictionary  because  design  objects  and 
artifacts  commonly  possess  project  specific  terms  and 
language.  Comprehension  of  these  terms  can  be  facilitated  by 
selectively  recalling  definitions  from  the  project  dictionary. 
A  tool  which  supports  this  functionality  could  use  hypertext 
terms  that  allow  the  users  to  click  on  specific  text  and 
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automatically  recall  detailed  definitions.  As  explained  in 
Chapter  IV,  this  functionality  is  available  in  the  Dedal  tool 
which  could  be  built  into  a  mechanism  which  implements  the 
design  rationale  information  model - 

5.  Constraint/Requirement  >  Source 

Design  may  be  viewed  as  a  constraint  satisfaction 
activity  where  some  constraints  are  explicitly  stated  in  the 
requirements  and  others  arise  from  the  refinement  of  the  basic 
requirements  through  design  activities.  Besides  explicit 
representation  of  the  constraints,  ability  to  trace  where  the 
constraints  came  from  would  help  in  design  situations  where 
constraints  need  to  be  relaxed. 

6.  Representation  of  All  Alternatives 

Issues  are  resolved  by  evaluating  alternatives.  It  is 
not  sufficient  to  capture  only  the  alternatives  chosen  to 
resolve  an  issue  because  alternatives  that  are  discarded  for 
various  reasons  may  become  relevant  in  a  changed  context.  As 
assumptions,  constraints,  or  requirements  change,  the 
discarded  alternatives  may  be  preferred  over  the  "chosen"  one. 
In  the  absence  of  a  complete  record  of  various  alternatives 
considered,  resources  must  be  dedicated  to  reformulating  these 
from  scratch.  To  phrase  it  in  layman's  terms:  "the  designers 
may  be  reinventing  the  wheel."  A  model  that  allows  for  the 
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Identification  and  isolation  of  the  alternatives  such  as  REMAP 
primitives,  position  and  argument  may  alleviate  this  problem. 

7.  Design  Rationale  and  Artifact  Linkages 

Very  often  interest  revolves  around  reusing  the 
artifact  rather  than  the  rationale.  Indicating  clear  linkages 
between  design  objects,  or  artifacts,  and  the  design  rationale 
will  help  in  the  understanding  of  the  context  in  which  the 
artifacts  were  created.  Many  available  models  for  design 
rationale,  such  as  gIBIS,  capture  only  the  design  rationale 
but  provide  no  discernable  link  to  the  artifacts  produced 
using  this  design  rationale.  Ideally  the  user  should  be  able 
to  select  a  design  object  and  accumulate  all  the  design 
rationale  used  to  create  it.  This  information  is  especially 
important,  in  an  evolutionary  system  design  situation  where 
changes  will  inevitably  be  made  to  the  design  object  as  the 
project  progresses.  Excunples  of  such  a  linkages  are  the 
relationships  between  design  objects  and  the  decision 
constraints  in  REMAP. 

C.  GENERIC  FUNCTIONALITIES 

The  design  rationale  information  model  components  we  have 
suggested  would  be  the  basis  from  which  a  tool  to  capture  and 
use  design  rationale  could  be  built.  Any  tool,  in  order  to 
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provide  maximxam  assistance  to  the  user,  would  need  to  provide 
at  least  the  following  generic  functionalities: 

1.  Semi -Structured  Tallorable  Environment 

An  important  consideration  in  the  development  of  a 
model  for  design  rationale  capture  and  use  is  the  degree  of 
structure  that  could  be  imposed  with  such  a  model.  A  totally 
unstructured  capture  of  design  rationale  information  will 
significantly  affect  the  potential  for  its  use.  Simply 
videotaping  the  design  activities  that  lead  to  the  formulation 
of  design  rationale  would  be  an  example  of  such  unstructured 
capture.  On  the  other  hand,  videotaping  can  provide  a  non- 
intrusive  means  of  capturing  design  information.  Although  a 
very  structured  information  model  may  constrain  the  designer 
and  may  prove  to  be  intrusive,  the  information  captured  may  be 
in  a  more  useable  format. 

We  see  the  answer  as  a  compromise  between  the  two 
extremes,  a  semi -structured  environment  where  a  flexible 
design  rationale  information  model  could  be  easily 
implemented. 

As  stated  by  the  design  team  of  NETWORK - HYDRA : 

Perhaps  the  single  most  difficult  problem  in  getting 
information  into  the  various  components  of  group  memory  is 
that  of  motivating  designers  to  impart  this  information. 
Nowhere  is  this  problem  more  difficult  than  in  the  input 
of  design  rationale  (Fischer,  et  al.,  1992,  p.286) . 
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Additionally,  they  state  a  possible  solution  to  this 
problem  is  creating  an  environment  in  which  the  designers  see 
the  need  or  benefit  of  capturing  design  rationale  as  a  part  of 
the  task  of  designing.  A  mechanism  which  provides  for  a  semi- 
structured  environment  in  the  capture  process  would  greatly 
facilitate  the  use  of  such  a  system.  NETWORK-HYDRA  has 
accomplished  this  by  providing  a  template  from  which  the 
designers  are  able  to  create  their  own  design  environment: 

An  important  principle  for  our  approach  is  that 
designers  are  more  likely  to  use  and  to  add  to  group 
memory  of  design  rationale  if  they  do  not  have  to  create 
project  rationale  entirely  from  scratch  (Fischer,  et  al., 
1992,  p.  286)  . 

To  employ  the  design  rationale  information  model,  we 
believe  the  semi -structured  environment  must  at  least  allow 
for  three  basic  conditions. 

First,  the  model  employed  within  the  environment 
should  emulate  the  natural  aspects  of  design  process  such  as 
deliberations,  similar  to  the  gIBIS  tool,  so  that  its  use  is 
viewed  by  stakeholders  as  conducive  to  the  design  cycle,  yet 
it  should  remain  tailorable  so  idiosyncracies  of  the 
stakeholders'  interests  can  be  captured.  One  such  example  of 
attempting  to  provide  a  structure  which  was  a  reasonable 
representation  of  design  processes  is  ConversationBuilder . 
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The  creators  of  the  tool  believe  that  most  design  activities 
center  around  conversations  between  designers,  therefore  they 
developed  a  tool  which  they  believe  could  enable  the  capture 
of  conversations.  Second,  ideally  the  environment  for 
employment  of  the  model  should  be  non- intrusive  so  that  it 
does  not  disrupt  the  work  flow  process.  Last,  by  allowing 
tailoring  of  the  model,  the  environment  could  provide 
assistance  across  a  spectrum  of  design  areas  from  mechanical 
construction  scenarios  to  software  design  projects. 

2 .  Information  Capture 

As  the  size  of  projects  increases,  the  number  of 
design  rationale  used  to  create  artifacts  skyrockets. 
Believing  that  any  one  architecture  can  formally  capture  all 
aspects  of  large  design  projects  is  unrealistic.  The  use  of 
video  taping  offers  the  capability  to  capture  entire  secjuences 
of  group  interactions.  Video  clips  could  be  categorized  under 
hypertext  headings  and  attached  to  various  nodes.  At  later 
times  the  categorized  information  could  be  filtered  should  it 
become  pertinent.  For  example,  a  video  clip  could  be  made  of 
a  session  where  a  particular  assumption  is  being  explored. 
Instead  of  textually  detailing  every  interaction  of  the 
session,  the  video  clip  could  be  attached  to  the  assumption 
and  should  further  review  of  the  assumption  be  necessary  the 
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video  clip  would  be  available  simply  by  clicking  on  a 
hypertext  node. 


The  ability  to  recall  sessions  at  a  later  time  is 
important  because  material  which  is  irrelevant  under  one  set 
of  requirements  or  constraints  may  become  relevant  as 
requirements  are  refined  in  the  design  life  cycle  or  data  that 
is  trivial  to  one  issue  may  be  relevant  in  other  domains. 

3 .  Representation  Language 

The  design  rationale  information  model  components 
capture  the  rationale  about  the  refinement,  elaboration  and 
modification  of  initial  requirements  or  constraints  that 
eventually  lead  to  design  artifacts.  In  order  to  support  the 
representation  and  reasoning  with  such  rationale  a  fairly 
powerful  representation  language  is  needed. 

The  design  rationale  would  be  stored  in  a  knowledge 
base;  therefore,  the  language  must  provide  facilities  to 
construct,  query,  and  maintain  structured  knowledge  bases. 
The  content  of  such  knowledge  bases  would  consist  of 
interconnected  information  model  components  that  are 
incrementally  modified. 

The  language  should  be  capable  of  representing  the 
ontology  of  design  rationale  in  terms  of  the  suggested  model 
components  and  should  provide  mechanisms  to  populate  the 
design  rationale  information  model  with  specific  instances. 
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The  language  should  also  provide  automatic  inferencing  to 
enable  access  to  the  design  rationale  which  is  implicit  in  the 
model  and  provide  mechanisms  to  maintain  integrity  of  the 
knowledge  base  (Dhar  and  Ramesh,  1992,  pp.  502-503) .  Such  a 
language  could  also  provide  a  basis  upon  which  a  decision 
support  system  could  be  constructed  to  further  assist  the 
users  in  such  tasks  as  assessing  the  feasibility  of 
alternatives  or  analyzing  how  a  change  in  one  area  may  affect 
other  areas. 

4 .  Information  Exchange 

The  exchange  of  information  between  individuals  is  a 
primary  activity  in  large  scale  design.  Easy  exchange  of 
information  is  a  basic  characteristic  which  should  be 
supported.  By  sharing  information,  designers  can  gain 
insights  which  could  potentially  strengthen  their  design 
rationale.  Electronic  "whiteboards,"  shared  editors,  and 
virtual  conference  rooms  allow  such  exchanges  to  take  place 
faster  and  more  efficiently. 

5.  Simultaneous  Work 

To  avoid  duplication  of  efforts  and  maximize  design 
talents,  simultaneous  work  between  project  personnel, 
regardless  of  their  relative  locations,  should  be  supported. 
In  addition  to  fostering  information  exchange,  the  methods 
mentioned  in  the  previous  subsection  will  also  enable 


simultaneous  work  at  geographically  distributed  locations. 
This  is  made  possible  by  users  being  able  to  simultaneously 
access  a  central  knowledge  base  with  browsing  and  modification 
capabilities.  At  the  recent  Groupware' 93  conference  and 
exhibition  in  San  Jose,  California,  many  tools  which  allowed 
asychronous  and  geographically  distributed  exchange  of 
information  were  displayed. 

6.  Levels  of  Granularity 

Reuse  of  a  design  rationale  knowledge  base  requires 
that  the  user  must  be  able  to  traverse  through  stored 
information  with  ease.  The  ability  to  browse  through  the 
contents  of  the  knowledge  base  at  different  levels  of 
granularity  will  greatly  enhance  the  usefulness  of  the 
knowledge  base.  For  example,  a  project  manager  may  want  to 
look  at  issues  at  the  highest  level  in  terms  of  hardware  and 
software  issues.  He  may  not  want  to  see  how  issues  at  this 
level  are  broken  down  into  sub- issues  for  resolution.  A 
designer,  on  the  other  hand,  may  be  interested  in  detailed 
descriptions  of  one  these  nodes.  By  allowing  users  to  choose 
which  level  of  granularity  they  wish  to  view,  information 
overload  can  be  avoided.  The  Graphical  Browser  provided  in 
the  gIBIS  tool  is  an  example  of  such  a  hierarchical 
representation  of  data. 
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7.  Color  Coding  of  Model  Primitives 

As  the  network  of  design  rationale  information  could 
explode  into  several  hundreds  or  even  thousands  of  nodes  and 
links  in  a  large  scale  project,  easy  visual  identification  of 
various  types  of  nodes  and  links  would  provide  valuable 
assistance  for  navigating  through  such  a  network.  REMAP  and 
NETWORK- HYDRA  both  incorporate  color  coding  schemes  and  use  of 
different  shapes  to  clearly  identify  various  primitives.  The 
design  rationale  information  model  could  also  emulate  such  a 
color  coding  scheme. 

8.  Cataloging  of  Decisions 

Similar  decision^  are  made  time  and  again  over  the 
life  span  of  a  project  or  even  across  similar  projects, 
therefore,  the  ability  to  identify,  track,  and  make  inferences 
about  such  relationships  should  exist.  An  indexing  system 
should  allow  the  users  to  classify  decisions  by  decision 
types.  Such  an  indexing  system  will  facilitate  the 
development  of  a  Decision  Support  System  (DSS)  to  assess 
degrees  of  similarities  between  decisions,  help  identify  when 
decisions  conflict  with  one  another  or  perhaps  even  illustrate 
otherwise  inexplicit  relationships  between  decisions.  A  DSS 
could  also  assist  in  understanding  their  relationships.  An 
indexing  system  such  as  the  one  in  Dedal  could  be 
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incorporated  into  a  design  rationale  capture  tool  such  as 


REMAP. 

9.  Decision  Support  Facilitation 

In  the  context  of  group  design,  mechanisms  that 
facilitate  arriving  at  a  group  solution  will  be  valuable. 
Multi -Criteria  Decision  Making  (MCDM)  methods  may  be  employed 
to  evaluate  positions  and  arguments  to  arrive  at  a  group 
solution. 
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VI.  RECOMMENDATIONS  AND  CONCLUSIONS 


Doing  more  with  less  in  the  shrinking  budgets  of  both 
industry  and  within  the  Department  of  Defense  necessitates  the 
reevaluation  of  current  and  past  practices.  In  this  thesis, 
we  have  suggested  one  way  to  refocus  the  practices  in  the  area 
of  design  by  concentrating  on  the  design  process  itself  rather 
than  the  products  of  the  process.  Specifically,  attention 
should  be  directed  at  the  capture,  understanding,  and  reuse  of 
design  rationale. 

We  have  suggested  the  basic  components  which  should  be  in 
a  design  rationale  inf ormation  model ;  discussed  the  importance 
of  such  components;  explored  examples  of  current  technologies 
and  models  that  exist  to  capture  such  components;  and 
suggested  the  generic  functionalities  of  a  tool  which  could  be 
used  to  employ  the  design  rationale  information  model. 

We  believe  this  thesis  contains  the  foundations  upon  which 
a  specific  design  rationale  information  model  can  be  built. 
By  incorporating  existing  technologies,  such  as  those 
presented  here,  we  believe  a  semi- structured,  non- intrusive 
architecture  could  be  constructed  to  provide  virtual 
communications  between  all  the  stakeholders  who  ever 
participated  in  any  aspect  of  design  deliberations.  Providing 
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virtual  communications  would  allow  for  effective  and  efficient 
capture  and  reuse  of  a  plethora  of  design  rationale  and  enable 
the  users  to  actually  do  more  with  less. 
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